home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19990725-20000114 / 000463_news@columbia.edu _Fri Jan 14 03:02:15 2000.msg < prev   
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id CAA26687
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 14 Jan 2000 02:55:15 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id CAA17724
  7.     for kermit.misc@watsun.cc.columbia.edu; Fri, 14 Jan 2000 02:30:33 -0500 (EST)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. Subject: Re: MS-DOS Kermit, more capabalities
  10. From: cangel@famvid.com
  11. Message-ID: <66Af4.3341$0l4.96678@tw12.nn.bcandid.com>
  12. Organization: bCandid - Powering the world's discussions - http://bCandid.com
  13. Date: Fri, 14 Jan 2000 07:19:31 GMT
  14. To: kermit.misc@columbia.edu
  15.  
  16.  
  17. On 1900-01-13 jrd@cc.usu.edu(JoeDoupnik) said:
  18.  
  19. JD> Newsgroups: comp.protocols.kermit.misc
  20.  
  21. --8<--cut 
  22.  
  23. JD> > While  I  have your attention: I've been compiling and fiddling with the
  24. JD> > WATTCP package which claims to have a part of it's code inside MSKermit.
  25.  
  26. JD> Wattcp  and  MSK  are  now  very  different  animals for TCP/IP work. That
  27. JD> divergence  started  when  Erick  very  generously offered his code to the
  28. JD> project.  The  gulf spread very quickly very widely. Today there is little
  29. JD> resemblence.  The  MSK  TCP/IP stack is modern and robust, but it is not a
  30. JD> library  or  other exportable form. Its internal applications, such as say
  31. JD> the DHCP client, are also modern. 
  32.  
  33. More reasons to view the source code. 8) 
  34.  
  35. JD> > MSKermit  is  many  times  more stable than the demo apps that come with
  36. JD> > the  WATTCP  source  (operation online is `intermittent' with send being
  37. JD> > exremely  poor  and  receive seems locked into something less than 9k6).
  38. JD> > MSKermit  OTOH  seems  to  move right along using the same packet driver
  39. JD> > and achieves 90% of theoretical max transfers on a regular basis.
  40.  
  41. JD> The  MSK code is designed to work solidly with Packet Drivers and Novell's
  42. JD> ODI drivers. It's not a series of approximations. It is robust by design. 
  43.  
  44. JD> > Question:  could  you  direct  me  to  any particular part of the WATTCP
  45. JD> > based  code  in the MSKermit source that would reveal how MSKermit seems
  46. JD> > to be so much better than the `original'? 
  47.  
  48. I  would  be  making  a  mistake  to  _not_  view the source code for MSKermit
  49. considering all that you've said. 
  50.  
  51. The  problem  is  that  one v315 is in BOO which I have no way to decipher and
  52. the other is a UUE of over a meg. 
  53.  
  54. Is  there a binary archive of this source code anywhere that I can download or
  55. am I going to need a way to decode a 1meg+ UUE?  Why would the MSKermit source
  56. code be in two ASCII formats when kermit itself has no problem doing binary
  57. transfers nor do any other protocols I am of aware of since the '80s?
  58.  
  59. >
  60. >        ,                          ,
  61. >      o/      Charles.Angelich      \o       ,
  62. >     <|        @AngelFire.com        |>  __o/
  63. >     / >          USA, MI           < \   __\__
  64.